Skip to content

Conversation

@bdice
Copy link
Contributor

@bdice bdice commented Apr 24, 2025

Description

This PR is a starting point for #1779.

It converts RMM to a precompiled shared library, and moves some implementations into src/ files.

Checklist

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.

@copy-pr-bot
Copy link

copy-pr-bot bot commented Apr 24, 2025

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@bdice
Copy link
Contributor Author

bdice commented Apr 24, 2025

/ok to test

@github-actions github-actions bot added the CMake label Apr 24, 2025
@bdice bdice added feature request New feature or request breaking Breaking change labels Apr 24, 2025
{
return is_pow2(alignment);
}
[[nodiscard]] RMM_EXPORT bool is_supported_alignment(std::size_t alignment) noexcept;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I believe RMM_NAMESPACE already contains the RMM_EXPORT macro, but it's not bad to be explicit. If we wanted to, we could then go back to just saying namespace rmm in this file.

We should, however, probably add RMM_EXPORT to the static symbols as well in that case.

Copy link
Contributor Author

@bdice bdice Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation! I was unsure about this. I will think some more about what solution seems the most natural. Related to the other comment below, I would like it if we could use either RMM_NAMESPACE or namespace rmm in both headers and implementation files -- but that is tricky with the need to export things.

What do you think of this proposal:

  1. get rid of RMM_NAMESPACE
  2. don't put RMM_EXPORT on every symbol, just the namespaces as we currently do
  3. use namespace RMM_EXPORT rmm in the headers and namespace rmm in the implementation files

Copy link
Contributor Author

@bdice bdice Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the topic of namespacing, I think there will also be a lot of detail functions that we can move from headers to implementation files in anonymous namespaces. (Currently we can't use anonymous namespaces because it's header-only and that's not good practice.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrt the proposal, that sounds reasonable. Ideally we move to a situation where everything in the detail namespace is __attribute__((visibility("hidden"))), similar to cudf last year:

I suppose your anonymous namespace suggestion would have the same effect.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for sure. That will likely be for a later pass. I haven't touched any "detail" headers yet.

#include <cstddef>
#include <cstdint>

namespace RMM_NAMESPACE {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe here we should be using namespace rmm since it is the header file which defines our public exported API.

@bdice bdice changed the title Add RMM shared library, convert aligned.hpp functions. Convert part of RMM to a precompiled library Apr 25, 2025
@bdice bdice added the DO NOT MERGE Hold off on merging; see PR for details label Apr 25, 2025
@bdice
Copy link
Contributor Author

bdice commented Apr 25, 2025

/ok to test

@bdice bdice marked this pull request as ready for review April 25, 2025 15:18
@bdice bdice requested review from a team as code owners April 25, 2025 15:18
@bdice bdice requested review from robertmaynard, vyasr and wence- April 25, 2025 15:18
@github-actions github-actions bot added the Python Related to RMM Python API label Apr 25, 2025
@bdice
Copy link
Contributor Author

bdice commented Apr 25, 2025

I'm going to cut the scope here for the first pass. I'd like to be sure that things work downstream before expanding the precompiled code further.

@bdice bdice requested a review from a team as a code owner April 27, 2025 19:14
@bdice
Copy link
Contributor Author

bdice commented Apr 28, 2025

This is now ready for review. I am going to do some downstream testing with cuDF before I remove the DO NOT MERGE label.

@bdice bdice requested a review from robertmaynard April 28, 2025 18:34
Copy link
Contributor

@vyasr vyasr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor notes, but generally LGTM.

CXX_STANDARD_REQUIRED ON
CXX_VISIBILITY_PRESET hidden
POSITION_INDEPENDENT_CODE ON
INTERFACE_POSITION_INDEPENDENT_CODE ON)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may be able to drop this eventually depending on how much of rmm stops being header-only. Ideally we wouldn't be proscribing this for consumers I think, @robertmaynard any thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally once RMM is a proper library we can drop INTERFACE_POSITION_INDEPENDENT_CODE but currently having it won't hurt downstream projects

#include <cstdint>

namespace RMM_NAMESPACE {
namespace RMM_EXPORT rmm {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the idea to get rid of RMM_NAMESPACE altogether eventually?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, see: #1896 (comment)

@jrhemstad
Copy link
Contributor

What's the ultimate goal here? Convert everything that can be part of a precompiled binary into one?

Strictly speaking, the only thing necessary to be part of a DLL is the current device resource machinery.

@vyasr
Copy link
Contributor

vyasr commented Apr 28, 2025

In my view the ultimate goal should be that if we are making rmm a shared library we should move anything that does not benefit from being header-only (for instance, non-template types that do not need to be inlined into performance-critical code paths) into the shared library. The current device resource machinery obviously needs to move for the uniqueness reasons, but moving other bits will also help us more easily make stability guarantees and reduce recompilation times across RAPIDS (right now a one-line change in the wrong place in rmm can bust sccache for the world, for example).

@bdice
Copy link
Contributor Author

bdice commented Apr 28, 2025

In my view the ultimate goal should be that if we are making rmm a shared library we should move anything that does not benefit from being header-only (for instance, non-template types that do not need to be inlined into performance-critical code paths) into the shared library. The current device resource machinery obviously needs to move for the uniqueness reasons, but moving other bits will also help us more easily make stability guarantees and reduce recompilation times across RAPIDS (right now a one-line change in the wrong place in rmm can bust sccache for the world, for example).

Yes -- all of the above here. Memory resources are the most important reason. Moving most code into a precompiled library also gives us stronger control over interfaces. We can shield implementation details behind anonymous namespaces and not need to expose them in detail (but "public") headers. We can start to have stability in our API/ABI that is more easily separable from implementation.

Copy link
Member

@harrism harrism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to leave this review at one question before I go on, because a lot of my opinions hinge on whether there's something I don't know about the answer to this question.

@bdice
Copy link
Contributor Author

bdice commented May 6, 2025

The next step needed for this is to add --exclude librmm.so to all the auditwheel invocations for downstream RAPIDS wheels using RMM (cudf, cugraph, ...).

@bdice
Copy link
Contributor Author

bdice commented May 7, 2025

I finished adding --exclude librmm.so to all the downstream libraries. I am doing final testing in rapidsai/cudf#18586 and then plan to merge this.

@bdice bdice self-assigned this May 7, 2025
@bdice
Copy link
Contributor Author

bdice commented May 8, 2025

I concluded my testing in rapidsai/cudf#18586 through a combination of CI jobs and local CI reproductions (I hadn't set up wheel artifact downloads properly in CI but all seems fine locally when installing RMM wheel artifacts from this PR). I also dealt with a fair bit of friction from the new GitHub Artifacts work. rapidsai/gha-tools#172 will fix those points of friction, making it easier to do future testing.

I am planning to merge this over the weekend so that I can avoid the possibility of Friday/weekend breakage, and help deal with any problems it may cause on Monday.

@bdice bdice removed the DO NOT MERGE Hold off on merging; see PR for details label May 11, 2025
@bdice
Copy link
Contributor Author

bdice commented May 11, 2025

/merge

@rapids-bot rapids-bot bot merged commit 8e19009 into rapidsai:branch-25.06 May 11, 2025
72 checks passed
@github-project-automation github-project-automation bot moved this from Review to Done in RMM Project Board May 11, 2025
vyasr added a commit to vyasr/rmm that referenced this pull request May 12, 2025
After rapidsai#1896 the librmm wheel contains a compiled library, which means it is no longer accurate to tag the wheel as supported on any platform. We must tag it according to the suitable architecture tags to ensure that we do not get arm binaries on x86 and vice versa. We must also add a manylinux tag to indicate glibc compatibility.

Authors:
  - Vyas Ramasubramani (https://github.com/vyasr)

Approvers:
  - Kyle Edwards (https://github.com/KyleFromNVIDIA)

URL: rapidsai#1913
rapids-bot bot pushed a commit that referenced this pull request Jul 11, 2025
Continues from #1896.

Contributes to #1779.

Authors:
  - Bradley Dice (https://github.com/bdice)

Approvers:
  - Lawrence Mitchell (https://github.com/wence-)
  - Rong Ou (https://github.com/rongou)
  - Robert Maynard (https://github.com/robertmaynard)

URL: #1980
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking Breaking change ci CMake conda feature request New feature or request Python Related to RMM Python API

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

7 participants